This chapter describes how to use the Frame Relay (FR) interface and includes the following sections:
The FR protocol is a method of transmitting internetworking packets by combining the packet switching and port sharing of X.25 with the high speed and low delay of time division multiplexing (TDM) circuit switching. FR allows you to connect multiple LANs to a single high-speed (1.54 Mbps) WAN link with multiple point-to-point virtual circuits (VCs). FR offers the following features:
The router can also initiate a slowdown of traffic when it receives a Consolidated Link Layer Management (CLLM) congestion message. CLLM is an optional part of the FR standards that provides additional management information about the operation of the frame relay network to attaching DTEs.
FR provides no error correction or retransmission function. To provide error-free end-to-end transmission of data, FR relies on the intelligence of the host devices.
The FR network consists of the FR backbone (consisting of FR switches provided by the FR carrier) providing the FR service. The router functions as the FR connection device. The router encapsulates FR frames and routes them through the
network based on a Data Link Connection Identifier (DLCI). The DLCI is the medium access control (MAC) address that identifies the PVC or SVC between the router and the FR destination device. For example, in Figure 17, router D receives packets from and sends packets to router B over DLCI 16 and router B receives packets from and sends packets to router D over DLCI 19. The FR provider is responsible for completing the circuit by connecting DLCI 19 attached to router B to DLCI 16 attached to router B. A similar relationship exists between router D and router A using DLCIs 17 and 18, respectively.
Figure 17. DLCIs in FR Network
A DLCI can have either local or global significance. Local DLCIs are significant at the point of entry to the network, but global DLCIs are significant throughout the network. To the user, however, the DLCI that the router uses to route a packet is the DLCI that the user associates with the frame's global or local destination. DLCIs are configured through the FR configuration process or learned through FR management.
FR PVCs are predefined connections used to route data through an FR network. The bandwidth allocated for a PVC within the network is a subscription option and must be allotted to the PVC whether or not the PVC uses it.
A FR network has the following characteristics:
FR subinterfaces are logical interfaces that are associated with an FR interface. You must define the FR interface, known as the FR base interface, before you configure one or more FR subinterfaces. The FR subinterfaces are said to be associated with the FR base interface.
After you create an FR subinterface, you can configure circuits over it just as you would over any FR interface. Note, however, that certain interface characteristics, such as compression and encryption, can be enabled and disabled only on the base interface.
Using FR subinterfaces has three main advantages:
The command to create an FR subinterface is add dev fr.
Example:
Config>add dev fr Enter the number of Frame Relay Subinterface interfaces [1]? Adding device as interface 4 Base net for the Frame Relay Subinterface interface(s) [0]? 3 Use "net " command to configure specific Frame Relay Subinterface parameters
FR Switched Virtual Circuits (SVCs) provide the ability to implement "cut-through" routing in an FR network, minimizing or eliminating intermediate router hops between DTEs. Network complexity can be simplified and the DTE may experience improved performance.
SVCs may replace PVCs to conserve network bandwidth, reducing bandwidth cost.
FR SVC standards are a subset of ISDN standards and provide many of the same advantages as ISDN with less complexity.
The following protocols are supported over FR SVCs:
SVCs cannot be required and cannot belong to a required group.
FR Frame Handler allows the 2212 to act like an FR switch. This function allows traffic to be forwarded between PVCs on FR interfaces without using the routing or bridging function. Its main purpose is to allow proprietary or unsupported routing protocols to be forwarded through the network device over FR PVCs. This can be done, for example, to connect a network device sending a proprietary protocol directly to a 2212 instead of to the FR network to save FR access costs. The proprietary traffic could then be forwarded over its own PVC through the FR network to the destination router, which could also be front-ended by a 2212. The 2212 can use different PVCs over the same FR interface to route and bridge traffic through the FR network to other destinations. Another example for the use of this function is to front-end a controller or router that does not support FR traffic shaping with a 2212 and to allow the 2212 to perform this function for it to reduce the number of frames that the FR network discards because of congestion.
As part of the frame handler function, the 2212 will support both explicit (BECN and FECN) and implicit (frame discards) congestion processing. If you enable CIR monitoring, it causes both the inbound and outbound CIR to be controlled. If either CIR or congestion monitoring are enabled, the configured outbound queue depth for the frame handler PVC will be enforced. Exceeding the CIR or the outbound queue limit will result in frames having BECN and FECN set in the appropriate direction and also in a frame discard condition.
If monitoring is not enabled, BECN or FECN are not set and frames will be forwarded over the interface as long as input buffers are available on the inbound interfaces. The 2212 now also supports the network side of the FR local management interface (LMI). This allows LMI to be used in back-to-back network device configurations. Network-side LMI is often used in frame handler configurations. However, this is not required. Also note that you can use the network side LMI without using the frame handler function in configurations where LMI is useful in back-to-back router configurations.
FH and voice forwarding cannot be used on the same circuit.
Figure 18 shows a typical FH configuration. On interface 1, PVCs 16 and 18 are defined as frame handler along with PVC 19 on interface 2 and PVC 20 on interface 3. All traffic received on these PVCs will be directly routed to their partner PVCs. Interface 1 is also shown supporting a DTE PVC. Data received over this PVC will be given to the appropriate routing function to be forwarded over any other interface in the network device.
Figure 18. DTE and DCE Circuit Multiplexing
Local Management Interface (LMI) is used to determine the status of PVCs on an FR interface. If an LMI is enabled, the FR interface is active when a successful exchange of LMI frames occurs between this router and the adjacent FR node; however, no data can be received from or transmitted to another router until an LMI status message indicates that the PVC status for the DLCI to the other router is active. Also, there are instances where the FR interface state is tied to PVC states and the interface does not come up even if LMI or Q.922 exchanges are successfully occurring (for additional information, see "Configuring PVC States to Affect the Frame Relay Interface State").
If LMI is not enabled and SVCs are enabled, the FR interface is active when a successful exchange of Q.922 frames occurs between the router and the adjacent device. All PVCs are considered active at this point. However, SVCs are active only after a successful Q.933 activation exchange.
PVC status appears for all PVCs as either active or inactive. An active PVC has a completed connection to an end system. An inactive PVC does not have a completed connection to an end system because either an end system or an FR switch is off-line.
For example, in Figure 19 router B has a configured PVC to router D. Router B is successfully interacting with FR management through FR switch B. Because either another FR switch is down or the end system is down, the end-to-end PVC connection is not established. Router B receives an inactive status for that PVC.
Figure 19. DLCIs in Frame Relay Network
The DSU connections must be configured to drop Data Set Ready (DSR), Clear To Send (CTS), or Data Carrier Detect (DCD) if the network connection is lost.
An orphan permanent virtual circuit is any PVC that is not configured for your router but is learned indirectly through the local management interface (LMI) connection with the frame relay provider. For example, Figure 20 assumes that router B has a configured PVC to router D, but none to router A. A circuit between routers A and B can be attained without configuring Permanent Virtual Circuits (PVCs) in the router. The FR provider configures a circuit using Data Link Connection Identifiers (DLCIs) between the ports where router A and router B are connected. Routers A and B, when communicating over the LMI, request status and in return get a message indicating the presence of Data Link Connection Identifiers (DLCIs). PVCs learned in this manner are called orphan circuits. Router B would then learn about the PVC to router A from LMI messages and classify it as an orphan.
Orphan PVCs are treated the same as configured circuits except that you may enable or disable their use with the enable orphan-circuit and disable orphan-circuit commands.
| Note: | All orphan PVCs will be used as DTE, not FH, circuits. Orphan PVCs cannot be used for voice forwarding or APPN(R). |
By disabling orphan circuits, you add a measure of security to your network by preventing any unauthorized entry into your network from a non-configured circuit. By enabling orphan circuits, you allow the router to forward packets over circuits you did not configure. Packets that would normally be dropped are now forwarded.
An orphan switched virtual circuit is an SVC that is not configured for your router but is created when a call-in is received for it. This is similar to Figure 20. However, Q.933 messages are used instead of LMI to generate the circuit and associate the appropriate parameters with it. Orphan SVCs are treated the same as configured SVCs except that you may enable or disable their use with the call-in option of the enable switched-virtual-circuit command.
You can control the operation of your FR interface by doing one of the following:
By enabling the FR No-PVC feature, the FR interface becomes inactive if there are no active PVCs on the interface. If at least one PVC is active, the FR interface becomes active when a successful LMI exchange occurs between the router and the FR switch.
You can configure a PVC as a required PVC. If a PVC is required but not in a group, the FR interface becomes inactive when the PVC becomes inactive. When the PVC becomes active, the interface is activated following a successful exchange of LMI frames between the router and the FR switch.
If multiple PVCs are required and are not in a PVC group, the interface is not activated until all required PVCs are active.
If a required PVC belongs to a PVC group, the FR interface becomes inactive when all PVCs in the PVC group are inactive. If at least one PVC in the group is active, the interface becomes active following a successful exchange of LMI frames between the router and the FR switch. If there are multiple PVC groups, the interface does not become active until at least one PVC in each group is active.
A required PVC group is a group of circuits associated by name, where name is the name of the required PVC group.
These features can be used with WAN Reroute so that an alternate link can be brought up if all PVCs, required PVCs, or a group of PVCs become inactive on the primary FR link.
For both base FR interfaces and FR subinterfaces, you can enable point-to-point. This option indicates whether the interface is point-to-point from the point of view of IP. If you configure an FR interface as point-to-point, unnumbered IP can run over the interface.
An FR frame consists of a fixed size address field with variable sized encapsulated user data. Figure 21 illustrates an FR frame format.
Figure 21. Frame-Relay Frame Format
8 7 6 5 4 3 2 1
Octet *---------------------------------------------*
1 | HDLC Flag = 0x7e |
*-----------------------------------*----*----*
2 | Data Link MSB/LSB (DL) |C/R | EA |
*-------------------------*----*----+----+----*
3 | Connection ID (CI) |FECN|BECN| DE | EA |
*-------------------------*----*----*----*----*
* *
. user .
. data .
. .
* *
*---------------------------------------------*
| Frame Check |
*---------------------------------------------*
| Sequence |
*---------------------------------------------*
N | HDLC Flag = 0x7e |
*---------------------------------------------*
Located in the first and last octet, these flags indicate the beginning and end of the frame.
This 10-bit routing ID resides in bits 3 to 8 of octet 2 and bits 5 to 8 of octet 3. The DLCI is the MAC address of the circuit. The DLCI allows the user and network management to identify the frame as being from a particular PVC. The DLCI enables multiplexing of several PVCs over one physical link.
This field's use is not defined within the FR standards and the field is passed transparently across the network.
This version of FR does not support extended addressing.
The FR backbone network sets this bit to 1 to notify the user receiving the frame that congestion is occurring for the PVC in the direction the frame is being sent. You can configure the device to slow down data transmission in the direction from which it receives a FECN using the enable throttle-transmit-on-fecn command. You can also set the BECN bit in data frames sent to the originator of the FECN using the enable notify-fecn-source command.
APPN High Performance Routing (HPR) uses detection of this bit set to allow Rapid Transport Protocol's adaptive rate-based flow and congestion control algorithm to adjust the data send rate. This algorithm prevents traffic bursts and congestion, maintaining a high level of throughput.
The FR backbone network sets this bit to 1 to notify the user that the frames sent by this router for this PVC have encountered congestion. The router then initiates a throttle down to a rate equal to or less than the user-defined CIR when CIR or congestion monitoring are enabled. The CIR for a PVC is supplied by the FR service provider and is configured using the add permanent-virtual-circuit command.
The FR network may discard transmitted data exceeding CIR on a PVC. The DE bit can be set by the router to indicate that some traffic should be considered discard eligible. If appropriate, the FR network will discard frames marked as discard eligible which may allow frames that are not marked discard eligible to pass through the network. To identify traffic that is discard eligible:
This field contains the protocol packet being transmitted. This field can contain a maximum of 8188 octets; however, the frame check sequence (FCS) can effectively detect errors only on a maximum of 4096 octets of data. The protocol data is preceded by an FR encapsulation header as defined in RFC 1490 and RFC 2427.
This field is the standard 16-bit cyclic redundancy check (CRC) that HDLC and LAPD frames use. This field detects bit errors occurring in the bits of the frame between the opening flag and FCS.
When the FR protocol receives a packet for encapsulation, it compares the packet's network address to the entries in the address resolution protocol (ARP) cache. If the ARP cache contains the DLCI number that matches the network address, the FR protocol encapsulates that packet into a frame and transmits the frame over its specified local DLCI. If the ARP cache does not contain a match, the FR protocol sends out an ARP request over all configured PVCs on the interface. When the appropriate end-point responds with an ARP response, the FR protocol adds its local DLCI that received the ARP response to the ARP cache. Subsequent data packets directed to the same network address are then encapsulated into a frame and sent out over its local DLCI.
Protocol addresses can be either mapped statically to FR network PVC addresses or SVCs using locally configured names or discovered dynamically through Inverse ARP or ARP. (For more information on ARP and Inverse ARP, see the Protocol Configuration and Monitoring Reference.) Either method is protocol-dependent as illustrated in Table 41.
| Note: | Static protocol addresses are also referred to as static ARP entries. A static ARP entry is added to the configuration with the add protocol-address command. |
Table 41. Protocol Address Mapping
| Protocol Type | ARP and Inverse ARP Usage | Static Mapping | VC Configured at Protocol Configuration |
|---|---|---|---|
| AP2 | Yes | Yes | No |
| IP | Yes | Yes | No |
| IPX | Yes | Yes | No |
| Banyan VINES** | No | No | No |
| DNA IV | Yes | Yes | No |
| OSI*, ** | No | No | Yes |
| * You must configure OSI at the protocol level to map the protocol address to the FR PVC. | |||
| ** Not supported using SVCs. | |||
Multicast emulation is an optional feature that allows protocols requiring multicast such as ARP to function properly over the FR interface. With multicast emulation, a multicast frame is transmitted on each active PVC. By using the enable and disable multicast commands, you can turn this feature on or off. Protocols that utilize multicast are AP2, ARP, Banyan VINES, DNA4, IP, and IPX.
Protocol broadcast is another optional feature that allows the IP RIP protocol to function properly over the FR interface. By using the enable protocol-broadcast and disable protocol-broadcast commands, you can turn this feature on or off.
For protocols that support ARP/InARP over FR, FR will only multicast a protocols packets over a circuit if a protocol address was either learned or configured for that circuit.
Multicast can also be enabled or disabled for an individual SVC. Use the multicast option on add switched-virtual-circuit.
The supplier of the FR network backbone provides FR network management. It is management's responsibility to provide FR end-stations (routers) with status and configuration information concerning PVCs available at the interface.
For PVCs, the FR protocol supports the ANSI T1.617 Annex D, ITU-T Q.933 Annex A (also referred to as CCITT Q.933 Annex A), and the Interim Local Management Interface (LMI) management entities. You can turn these entities on or off using the enable and disable LMI configuration commands. Once LMI is enabled, use the set command to select the LMI standard to be used and the LMI network type. The LMI standard, ANSI, CCITT, or REV1, must be compatible with the adjacent FR node. The LMI network type determines whether FR only requests status of the adjacent node, only provides status to the adjacent node, or does both simultaneously. The LMI network type must also be compatible with the adjacent FR node. Specifically, FR LMI provides the following information:
Although the FR interface supports PVC network management, it is not necessary for management to run on the FR backbone for the interface to operate over the FR backbone. For example, you may want to disable management for back-to-back configurations; however, this is not always necessary since FR provides both the user and network sides of the LMI management protocol.
For SVCs, the FR protocol supports FRF 4 (Frame Relay Forum Implementation Agreement 4). This includes an implementation of ANSI Q.922 and a subset of ANSI Q.933. Q.922 provides verification of the integrity of the physical link between the router and the network. Q.933 provides the means for establishing and disconnecting SVCs across the network. Q.922 and Q.933 are always enabled when SVCs are used.
Upon request, FR LMI provides two types of status reports, a full status report and a link integrity verification report. A full status report provides information about all PVCs the interface knows about. A link integrity verification report verifies the connection between a specific end station and a network switch. All status inquiries and responses are sent over DLCI 0 for ANSI T1.617 Annex D and ITU-T Q.933 Annex A, or DLCI 1023 for interim LMI management.
When the FR interface requires a full status report, the router's FR protocol sends a status enquiry message to the FR network backbone requesting a full status report. A status enquiry message is a request for the status of all PVCs on the interface. Upon receiving this request, FR management must respond with a full status report consisting of the link integrity verification element and a PVC status information element for each PVC (see "Link Integrity Verification Report").
The PVC status information element contains the following information: the local DLCI number for the particular PVC, the state of the PVC (active or inactive), and whether the PVC is new or an existing PVC that management already knows about.
| Note: | The number of PVCs supplied at the FR interface is restricted by the network frame size and the amount of individual PVC information elements that can fit into a full status report. For example, 202 is the maximum number of PVCs for a network with a 1-K frame size. |
The link integrity verification report, sometimes referred to as heartbeat polling, contains the link integrity verification element. This element is where the exchange of the send and receive sequence numbers takes place. By exchanging sequence numbers, management and the end station can evaluate the integrity of the synchronous link. The send sequence number is the current send sequence number of the message originator. The receiver looks at this number and compares it to the last send sequence number to verify that this number is incrementally correct. The receive sequence number is the last send sequence number that the originator sent out over the interface. It is the receiver's responsibility to place a copy of the send sequence number into the receive sequence number field. This way the originator can ensure that the receiver receives and interprets the frames correctly.
When an end-station fails to participate in this polling process, all remote end-stations with logically attached PVCs are notified through management's full status report mechanism that the PVC is inactive.
CLLM is an optional FR management function that is not widely supported by the industry but it has been adopted by some FR switch manufacturers. CLLM provides some of the same management information provided by LMI, in particular, outage notification. CLLM's main use is to provide asynchronous congestion notification of PVCs to attaching devices. A single CLLM message may indicate outage or congestion for multiple PVCs. The FR protocol supports the following standards for CLLM: ANSI T1.618, ITU-T (CCITT) Q.922 Annex A, and ITU-T (CCITT) X.36 Annex C.
This section introduces data rates for FR permanent virtual circuits (PVCs) and switched virtual circuits (SVCs).
The CIR is the data rate that the network commits to support for the VC under normal, uncongested conditions. Any VC that is configured or is learned is provided a CIR (by the FR network backbone provider). The CIR is a portion of the total bandwidth of the physical link of either 0, or between 300 bps and 6 312 000 bps* reserved for the VC. A value of 64 kbps for a single DS0 channel is most common.
You define the CIR with the add permanent-virtual-circuit, change permanent-virtual-circuit, add frame-handler, change frame-handler, add switched-virtual-circuit, or change switched-virtual-circuit configuration command. You can also dynamically change the CIR with the set circuit console command. You can also set the default CIR for all Frame Relay circuits on this interface using the set CIR-defaults command.
Some FR switches allow a value of 0 to be configured for CIR. When CIR is equal to 0, little or no bandwidth is reserved in the FR network backbone for the VC, and the VC's traffic uses non-reserved bandwidth.
The router assigns a CIR to orphan circuits based on the CIR defaults configured at the interface level. If you are relying on the orphan circuit to route important data and the CIR, Bc, and Be values from the network provider are different from the values configured at the interface level, it is recommended that you define a PVC instead of an orphan circuit. Doing this, you can assign a CIR that the network commits to support.
The committed burst (Bc) size is the maximum amount of data (in bits) that the network commits to deliver during a calculated time (Tc) interval. The Tc is equal to the Bc divided by the CIR (Tc = Bc / CIR). If you configure 0 for CIR, FR uses a value of 1 second for Tc.
For example, if you set a VC's CIR to 9600 bps and the committed burst size to 14 400 bits, the time period is 1.5 sec. (14 400 bits / 9600 bps = 1.5 sec). This means that the VC is allowed to transmit a maximum of 14 400 bits in 1.5 seconds.
| Note: | The minimum Tc supported by FR is 0.03 of a second. |
This parameter is important because of the relationship between the committed burst size and the maximum frame size. If the maximum frame size in bits is greater than the committed burst size, the network may discard frames whose size exceeds the committed burst size. Therefore, the committed burst size should be greater than or equal to the maximum frame size. It should also equal the burst size set up with the network provider.
Use the add permanent-virtual-circuit, change permanent-virtual-circuit, add frame-handler, change frame-handler, add switched-virtual-circuit or change switched-virtual-circuit configuration commands to set the committed burst size. The set circuit console command can be used to dynamically change the committed burst size. You can also set the default committed burst size for all FR circuits on this interface using the set CIR-defaults command.
The device assigns orphan circuits a committed burst size based on the default you set with the set CIR-defaults command. If you configure 0 for CIR, then the committed burst (Bc) size also equals 0.
The excess burst (Be) size is the maximum amount of uncommitted data the router can transmit on a PVC in excess of the Bc during the Tc (Tc = Bc / CIR) when CIR and Bc are nonzero. When CIR = 0, FR uses a value of 1 second for Tc.
The network delivers this excess data with a lower probability of success than committed burst size data. Set the Be to a value greater than zero only if you are willing to accept the risk of discarded data and its effect on higher-layer protocol performance. The Be should equal the value set up with the network provider.
Use the add permanent-virtual-circuit, change permanent-virtual-circuit, add frame-handler, change frame-handler, add switched-virtual-circuit or change switched-virtual-circuit commands during frame-relay configuration to set the excess burst size. You can also use the set circuit console command to dynamically change the excess burst size. Orphan circuits will receive a default excess burst size equal to the value set in the set CIR-defaults command. If you configure 0 for CIR, then you must configure a nonzero value for the excess burst (Be) size. You can also set the default excess burst size for all FR circuits on this interface using the set CIR-defaults command.
The line speed is the interface's line speed.
The FR interface's line speed is configured using the set line-speed configuration command. The line speed must be configured when internal clocking is used. However, it is recommended that you configure a line speed for external clocking since the router uses the line speed as the maximum information rate when congestion monitoring is enabled. Also some of the protocols use an interface's configured line speed when calculating a route's cost.
The line speed is not configurable on an FR dial circuit interface. If the dial circuit is mapped to an ISDN base interface, 64 kbps is used as the line speed.
For dial circuits using Channelized T1/E1 as the base net, the line speed is 64 kbps times the number of timeslots assigned or 56 kbps if you set the bandwidth of the Channelized circuit to 56 kbps. For example, if you set the number of timeslots for a Channelized circuit to 3, the line speed is 192 kbps (3 * 64 kbps).
If the dial circuit is mapped to a V.25 bis base interface, the line speed of the V.25 bis interface is used for the FR dial circuit.
The minimum information rate (IR) is the minimum data rate for a VC that the router throttles down to when it is notified of congestion. You set the minimum IR as a percentage of CIR using the set ir-adjustment configuration command. It can be dynamically changed using the set ir-adjustment console command. If you configure CIR equal to 0, the minimum IR is 1500 bps.
The maximum information rate is the maximum data rate at which the router transmits for a VC. If the CIR monitoring feature is enabled and CIR and Bc are nonzero, the maximum information rate is calculated using CIR, Bc, and Be as follows:
( Bc + Be ) per Tc interval
If the CIR monitoring feature is enabled and CIR and Bc are configured equal to 0, the maximum information rate is equal to the excess burst size (Be) per second.
If the CIR monitoring feature is not enabled the maximum information rate is equal to the line speed.
The variable information rate (VIR) ranges from the configured minimum IR to the calculated maximum IR when the CIR monitoring or congestion monitoring features are enabled. The VIR is gradually decreased down to the minimum information rate when the router is notified of congestion on a circuit and is gradually increased to the maximum information rate when the router stops receiving congestion notifications. Using the set ir-adjustment configuration command, you configure the percentage of the information rate by which the VIR should decrease when the router is notified of congestion. You also use this command to configure the percentage of the information rate by which the VIR should be gradually increased when the congestion ends.
To avoid impulse loading of the network, the router initially sets the VIR to CIR when the VC becomes active. If you configure 0 for CIR, VIR is initially set to excess burst (Be) times the MIR adjustment percentage. For example, if Be is set to 64 000 and the MIR adjustment percentage is set to 25%, then the initial VIR would be equal to 16 000 bps.
The VIR can actually exceed the maximum value in one case. If the length of a frame in bits is greater than the maximum IR, FR transmits the frame anyway.
| Note: | Frame Handler (FH) circuits do not use a VIR. The send rate for an FH circuit remains at the maximum-sent rate confirmed for the circuit. |
| Note: | FH circuits, like other circuits, use FR frames to determine when congestion occurs and to notify the routers. However, they have their own methods for monitoring and handling circuit congestion. See Frame Handler Circuit Congestion for more information. |
Circuit congestion occurs for one of the following reasons:
If circuit congestion occurs, the network must drop packets, or shut down, or both.
In response to circuit congestion, the router implements a throttle down, which is a step-wise slowing of packet transmission to the configured minimum IR. Throttle down occurs during the following conditions:
The following topics discuss monitoring FR data rates and circuit congestion.
CIR monitoring is an optional FR feature that you can set for each interface to prevent the router from creating congestion conditions in the FR network. CIR monitoring allows the VIR for a VC to range between the configured minimum and maximum IR.
CIR monitoring is configured with the enable cir-monitor configuration command and is disabled by default. CIR monitoring, when enabled, overrides congestion monitoring. You can also dynamically enable and disable CIR monitoring using the enable cir-monitor and disable cir-monitor console commands.
Congestion monitoring is an optional feature, set per interface, that allows the VIR of VCs to vary in response to network congestion. The VIR assumes values between the minimum IR and a maximum IR of the line speed. Congestion monitoring is enabled by default. It can be disabled with the disable congestion-monitor configuration command and re-enabled with the enable congestion-monitor command. You can also dynamically enable and disable congestion monitoring using the enable congestion-monitor and disable congestion-monitor console commands.
CIR monitoring, if enabled, overrides congestion monitoring. If both CIR monitoring and congestion monitoring are disabled, the VIR for each VC on the interface is set to the line speed and does not decrease in response to network congestion.
| Note: | Even with compression enabled, the device uses the uncompressed size of frames to determine if the VIR is being exceeded. |
If congestion occurs, the FR backbone network is responsible for notifying the sender and receiver by sending out a FECN or a BECN signal. FECN and BECN are bits that are set in a frame to notify the
DTEs at each end of a VC that congestion is occurring. FECN indicates that congestion is occurring in the same direction from which the frame was received; the sender is causing the congestion. BECN indicates that the frames sent by this DTE are causing network congestion.
Optionally, the network can use CLLM messages to convey congestion information for PVCs. CLLM messages are sent only to the congestion source and should be treated similarly to BECN messages by the DTE.
The example in Figure 22 shows a congestion condition at switch B when frames are sent from router X to router Y. The FR backbone network notifies router X that frames it sends are encountering congestion by setting the BECN bit in frames sent to router X. The FR backbone network also notifies router Y that frames it receives encountered congestion by setting the FECN bit.
If the router receives a frame containing BECN, it is the router's responsibility to throttle down the VC's variable information rate (VIR) if either CIR monitoring or congestion monitoring is enabled. The router does this gradually as it receives consecutive frames with BECN until either the minimum IR is reached or a frame without BECN arrives. FR switches often set BECN in multiple frames after reaching a congestion threshold. In order for FR to avoid overreacting to network congestion when the network is setting multiple frames with BECN, FR will decrease a VC's VIR at most once every second. This allows the VIR to decrease gradually. As the router receives consecutive frames without BECN, the VIR gradually rises to the maximum IR.
Depending on the operation of the FR network, it may be necessary for the device to throttle down the VC's VIR when the device receives a FECN to minimize the overall amount of traffic being offered to the network as quickly as possible. Reducing the overall load on the network reduces the number of packets discarded for all VCs to relieve congestion. Enabling the throttle-transmit-on-fecn parameter, along with either the CIR or congestion monitoring options, causes the device to treat a FECN like a BECN thus reducing overall FR network congestion when any congestion notification is received. Use the throttle-transmit-on-fecn parameter only in FR networks whose queuing methods do not provide dedicated buffers for both input and output. If the throttle-transmit-on-fecn is enabled, FR will decrease a VC's VIR at most once every second for each BECN or FECN received.
Some FR network switches set FECN to indicate congestion but do not set BECN. To provide congestion notification to the source of the congestion, enable the notify-fecn-source parameter allowing the device to set BECN in frames that it transmits over a VC on which it has received a FECN. This action provides a signal to the device that is causing the network congestion to throttle down its VC's VIR.
Figure 22. Congestion Notification and Throttle Down
| Note: | If multiple DLCIs are configured between two end-stations when congestion occurs, it is possible that a second DLCI may be used to transmit data at a higher throughput until the congestion condition on the first DLCI is corrected. |
Similarly, if the network provider supports CLLM, you can configure FR to throttle down its transmit rate for PVCs contained in a CLLM message. CLLM messages contain a cause code that indicates the type and severity of the problem being reported. The device reacts differently depending on the cause code and the CIR configured for each PVC contained in the CLLM message. When the device receives a CLLM message that indicates:
Once a CLLM message for a PVC has been received, if the device does not receive any CLLM messages or BECNs within the Ty timer period or if a frame without a BECN is received, the device will consider the congestion condition cleared and gradually return the PVC to its configured transmission rates. If you are using CLLM to control congestion, you must not configure DLCI 1007 for any other use.
Acting as part of the FR switching network, Frame Handler (FH) circuits can perform congestion control and monitoring in a similar way to DTE circuits. When either CIR or congestion monitoring are enabled on an interface on which an FH circuit is defined, the FH circuit and its partner circuit work together to control the rate of data through the router and to notify the attaching DTE circuits when congestion occurs. It is then the responsibility of the DTE to react to the congestion indications set by the FH circuits.
Note that unlike DTE circuits, FH circuits do not use a variable information rate. The send rate for an FH circuit is set to its configured value and never changes. Again, it is up to the DTE to change its send rate in reaction to congestion. The router will preserve the BECN/FECN/DE bit settings in frames that it is forwarding if the bit was already set by either the DTE or by another switch or router in the path; that is, FH will not turn the bits off, but it may turn them on.
Congestion processing for the FH PVCs can operate in one of three modes: CIR monitoring, congestion monitoring, and no monitoring. The type of monitoring used for a given FH PVC is determined by what is enabled on the outbound interface. For example, if you want to enable monitoring of the receive information rate for FH PVCs, you must enable CIR monitoring on the outbound interface of the circuit. Although this seems somewhat confusing, it is most likely that the interfaces on which the partner FH PVCs are defined will both be configured for the same type of monitoring.
When you enable CIR monitoring, both the transmit and receive data rates will be monitored to ensure that they are kept with the configured values. A Tc of one second will be used on the receive side regardless of the CIR and Bc values. When the FH is processing a received frame, BECN will be set in the first frame queued for transmit in the opposite direction (if one exists) and FECN will be set in the first frame queued for transmit in the same direction (if one exists) if any one of the following conditions is true:
CIR monitoring is configured with the enable cir-monitor configuration command and is disabled by default. A frame will be discarded if the receive CIR is being exceeded by 10% or the maximum queue depth is exceeded. If a frame is to be discarded, then FR will discard the first frame that has the DE bit set and should be forwarded. If no frame with the DE bit is found, then the received frame will be discarded instead of being forwarded. CIR monitoring, when enabled, overrides congestion monitoring. You can also dynamically enable and disable CIR monitoring using the enable cir-monitor and disable cir-monitor console (Talk 5) commands.
When you enable congestion monitoring, the data rates for the circuit will not be monitored during transmit or receive. The BECN and FECN bits will be set under the following conditions:
A frame will be discarded if the configured maximum queue depth is exceeded by receiving an incoming frame. If a frame is to be discarded, then FR will discard the first frame in that has the DE bit set and should be forwarded. If no frame with the DE bit is found, then the received frame will be discarded instead of being forwarded. Congestion monitoring is an optional feature that can be set per interface. Congestion monitoring is enabled by default. You can disable it with the disable congestion-monitor configuration command and reenable it with the enable congestion-monitor command. You can also dynamically enable and disable congestion monitoring using the enable congestion-monitor and disable congestion-monitor console (Talk 5) commands.
When neither CIR nor congestion monitoring are enabled, the send and receive data rates will not be monitored and neither BECN nor FECN will be set. The DE bit will not be used when determining which frame to discard during congestion. Instead, if the input device is low on receive buffers and the fair value for the interface is exceeded, or if the outbound queue depth for the FH circuit reaches 100, the input frame will be discarded.
For information on bandwidth reservation over FR, refer to "Using Bandwidth Reservation and Priority Queuing" and "Configuring and Monitoring Bandwidth Reservation" in Using and Configuring Features.
The bandwidth reservation system (BRS) should be configured to prioritize the data frame fragments if fragmentation is enabled on an interface. See Fragmentation Over a Frame Relay Interface for details.
Voice over Frame Relay (VoFR) is a method to transmit voice packets over an FR circuit. If you plan to use one FR circuit to carry both real-time (voice) and data traffic, you should configure that circuit to fragment the data traffic, especially if the link is relatively slow, for example, 64 kbps. Fragmentation is also needed for circuits on interfaces that carry voice traffic and for circuits on interfaces that do not carry voice traffic themselves but communicate with interfaces that carry voice traffic.
There are two types of fragmentation, end-to-end and interface (or UNI/NNI). Interface-level fragmentation has not been implemented by any major FR switch vendors and so it is not available from any FR service providers. Per the FR implementation agreement, FRF.12, end-to-end fragmentation is supported for PVCs only. Therefore, an interface with voice support can be used to support FR PVCs, but not SVCs.
You can configure the fragment sizes. Fragment sizes are not negotiated or communicated between interfaces and therefore may be different for two interconnected PVCs. The fragment size may vary from one link or PVC to another depending on the access speed of the link, the CIR of the PVC, and whether this interface is actually carrying real-time data or is communicating with another router whose interface is carrying real-time data. Other factors to consider when configuring fragmentation for voice over frame relay include committed burst size, BRS traffic classes and queue depths if BRS is configured, the number of global buffers created, and the number of receive buffers allocated to each interface.
Because of the overhead associated with fragmentation, it is best to keep the fragment size as large as possible while still maintaining high quality real-time data communications.
If a circuit transmits real-time data, you should configure the Bandwidth Reservation System (BRS) in addition to FR fragmentation on that interface and circuit. Enabling BRS can give higher priority to real-time data over other data. As a result, real-time data can be interleaved between other data that has been fragmented so that the queueing delay for the real-time data can be minimized.
BRS is required only for circuits that will actually be sending real-time data and other data. Other circuits on the interface, or circuits that communicate with interfaces that support real-time data, do not specifically need BRS support to allow interleaving.
Refer to the assign command in the chapter "Configuring and Monitoring Bandwidth Reservation" in the Using and Configuring Features for more information about configuring BRS.
| Note: | You can configure fragmentation either for an interface or for a circuit
(also called a PVC). If you configure fragmentation for a PVC, you must
use the add permanent-virtual-circuit or the change
permanent-virtual-circuit command. The following example shows
the add permanent-virtual-circuit command:
FR 1 Config>add perm 18 Committed Information Rate (CIR) in bps[64000]? Committed Burst Size (Bc)in bits [64000]? 4800 Excess Burst Size (Be) in bits [0]? Assign circuit name : :? VoFRcircuit1 Is circuit required for interface operation [N]? Enable circuit for voice forwarding [N]? Do you want to have end-to-end fragmentation performed [N]? y Fragment size (50 to 1000) [256]? Fragmented packet reassemby timer (3 to 10 seconds) [256]? |
Voice forwarding over FR will enable a voice-capable or non-voice capable router to forward FRF.11 encapsulated packets, that is, voice packets, between FR PVCs without using a native voice adapter. This will allow a voice-capable router to multiplex voice and data over the same virtual circuit across the FR network. The voice-forwarding router will then route the received data using the protocol stack associated with the received traffic and forward the voice traffic to another PVC over the same or another FR interface. In a typical configuration, the voice traffic is forwarded to a locally attached voice-capable device.
Even though it is a DCE-like function, voice packet forwarding will be done over virtual circuits defined as DTEs. Voice forwarding will be allowed for PVCs only because voice over FR is supported for PVCs only.
A PVC that will be used for voice packet forwarding must be enabled through configuration to do so. In fact, a pair of PVCs on assumedly different FR interfaces must be defined to forward voice packets to each other. When you enable a PVC for voice forwarding, you must provide the net number and DLCI of the PVC to which the PVC should forward the voice packets. FR will forward all voice packets between the pair of PVCs defined to do voice forwarding.
Note that voice forwarding is not used to enable the voice adapter to communicate over an FR PVC. Enabling a PVC for voice (as opposed to voice forwarding) has to be configured at the voice adapter level. Voice forwarding is used to transmit voice packets between FR interfaces. Processing of the voice packets occurs only when the voice packets are transmitted to the voice adapter.
Through the use of statistical multiplexing, frame relay networks provide an excellent transport medium for data, but represent somewhat of a challenge for voice. The transit delay for each packet forwarded through a frame relay network is potentially different from that of the previous packet. And although frame relay networks ensure proper sequencing of frames, they do not ensure delivery of all packets; retry and recovery are left to higher layers. The delay of a given packet is mostly affected by the amount of additional network traffic present when the packet is being forwarded. There is a general rule of thumb that the round-trip response time for a voice packet should not exceed 250 milliseconds (ms); otherwise, the callers will begin talking over one another. To maximize the quality of the voice calls, your router network can be tuned to minimize the transient delay of voice packets.
There are a number of configurations that can be used to support Voice over Frame Relay (VoFR) and each one requires different tuning considerations. Frame relay fragmentation plays a key role in the configuration if the voice will be carried over relatively slow links (for example, 64 kbps). The frame relay CIR and committed burst size, BRS traffic classes and allowable queue depths, the number of global buffers created, and the number of receive buffers allocated to each interface also require consideration.
Fragmentation is required for all PVCs on any interface that will be used for voice or any other high priority, real-time data. There are two types of fragmentation: end-to-end and interface (or UNI/NNI). Interface-level fragmentation has not been implemented by any major FR switch vendors, and so it is not available through any FR service providers. Per the Frame Relay Forum implementation agreement, FRF.12, end-to-end fragmentation is supported only for PVCs. Therefore, an interface with voice support should not be used to support FR SVCs.
Fragmentation is necessary to minimize the amount of delay in queuing and transmitting voice packets. Fragmentation should be used for all PVCs that exchange data over an interface that is supporting voice. This means that a router that does not support voice still needs to perform fragmentation if it communicates with another router that is supporting voice over the same interface.
Fragment sizes may vary between FR interfaces, depending upon the access speed of the link, the CIR of the PVC, and whether this interface is actually carrying voice or just communicating with another router whose interface is carrying voice. Fragment sizes are not negotiated or communicated between interfaces, and therefore may be different for two interconnected PVCs. Because of the overhead associated with fragmentation, it is best to keep the fragment size as large as possible while still maintaining high-quality voice communications. The most important thing to remember is the 250-millisecond round trip delay limit. That means that any given component in the network must minimize its portion of the delay and yet maximize its efficiency.
When voice and data are multiplexed over the same PVC, the FR burst size and burst interval are also important in reducing the amount of delay incurred by voice packets. The burst interval, or Tc, is calculated by Bc/CIR (committed burst size divided by CIR). This specifies the duration of the burst. The burst size is the number of bits the router is configured to send during Tc. It is normally Bc+Be, but can be more or less, depending on whether CIR or congestion monitoring is enabled and whether any congestion indications have been received.
Assume for example, you have a CIR of 64 kbps, a Bc of 64 kbs, and a Be of 0; in this case, Tc is equal to one second. The router will allow a burst of up to 64 kbs anytime during that 1-second period. If there is data queued for the circuit, then the 64 kbs will be sent right at the beginning of the interval. The router must now wait until the next Tc, that is, the next second, before it can send any more data. This works well for file transfers and also works well for voice alone because the voice interface sends data to the FR interface at a steady, predictable rate, thereby eliminating the burst. But if the PVC is being used to transmit both voice and data traffic, then the voice could be queued for up to one second waiting for the next Tc interval, and this delay is unacceptable.
Figure 23. A Sample VoFR Configuration
Assume in this configuration that the 2212s, 2210s, and the 2216 each have a T1 access rate link to the FR network. The 2212s and 2210 each have a single PVC leading to the 2216. The 2216 therefore has a single PVC to each of the routers. PVCs to other routers are assumed to be on the same link. The 2216 also has a back-to-back FR link to the IBM 9783 Voice FRAD at T1 speed.
The following list describes the configuration considerations that must be made when configuring the 2212s:
As an example, assume a vocoder rate of 9.6 kbps. The 9.6 kbs represents the amount of data, minus headers, that will be used for the call, assuming no silence suppression. If frame packing is not used, the actual bandwidth used is 12 800 bps per call. So a PVC with a 64-kbps CIR can carry only four voice calls at the 9.6-kbps rate. A PVC carrying voice only does not need to be fragmentation capable; it is carrying only voice, and voice packets are not fragmented.
Table 42. Data Generated by a Voice Port
| Vocoder | Bits per second with overhead | Bytes per frame | Packets per second |
|---|---|---|---|
| 4800 | 8000 | 15 | 67 |
| 7500 | 10 670 | 20 | 67 |
| 8000 | 10 400 | 26 | 50 |
| 9600 | 12 800 | 25 | 67 |
| 16 000 | 19 200 | 36 | 67 |
| 32 000 | 35 200 | 66 | 67 |
This means that the PVC can send 3840 bits (480 bytes) per 60 ms. If it does this, then it will achieve a send rate of 64 kbps (60 ms = .06 seconds; 3840/.06 = 64 000 bps). The four voice calls will each generate one 25-byte frame every 15 ms. This means that in a 60-ms interval, the voice ports will be sending 400 bytes (25 bytes * 4 frames * 4 calls) per interval. This leaves 80 bytes per Tc to send data. Therefore, the fragment size should be set to 74 (80 - 6 bytes of overhead). In order for Tc to be strictly honored for a PVC, you must enable CIR monitoring for this interface.
As another example, assume that you have only two voice calls over the same PVC above. Tc should still be 60 ms, meaning that Bc must still be set to 3840. However, the fragment size will change, because a larger fragment may now be sent in the same Tc interval with the voice packets. In this case, the fragment size should be set to 274 bytes (480 - (25 * 4 * 2) - 6).
The considerations for tuning the 2216 are the same as for the 2212 because it is performing voice forwarding between the PVMs in the 2212s and the IBM 9783 Voice FRAD.
The 2210 is not sending any voice traffic; however, it is communicating with the 2216 interface that is sending voice traffic. In this case, the 2210 does not need any special tuning other than enabling the PVC for fragmentation. The 2210 PVC does not really need to fragment its outgoing packets, but fragmentation must be enabled to allow it to receive fragmented packets. Therefore, the fragmentation size for this PVC should be set to the MTU for the interface, or 8190, which is the maximum MTU for an FR interface. In either case, the 2210 will not be fragmenting frames it sends but will be reassembling those sent to it by the 2216.
Depending upon the number of voice calls supported and the access rates, you may also need to increase the number of input buffers per interface. Increased input buffers are required because of the queuing delays caused when FR runs burst timers. What generally happens on a T1 line is that the PVC will fill its burst size immediately and then pause for Tc (60 ms in the above example) before sending again. This will mean that the circuit will queue 60 ms worth of voice frames before sending again. Flow control mechanisms in the router can cause voice packets to be discarded so that transmission is affected before you notice a problem with the voice quality. Transmission problems are indicated when voice calls are hung up by the voice adapter or a voice call cannot be initiated even when the bandwidth is available.
In these cases, it may be necessary to increase the number of receive buffers on both the FR and voice adapter interfaces. The best way to monitor dropped frames is by using the Talk 5 error and interface commands. If input discards on the voice adapters or missed frames on either the voice or FR interfaces are detected, you should increase the number of receive buffers. However, input and output discards on the FR interfaces may be normal and acceptable if any of the FR circuits are being overloaded with data, for example, when the 2212 is attempting a large file transfer while four voice calls are active.
It is necessary to configure BRS on all interfaces that are supporting both voice and data. BRS can be used to control both the number of buffers that can be queued for a given circuit and the priority given to the data that is being queued.
The minimum and maximum queue depths are configured per circuit at the BRS level. These queue depths apply to each of the four queues in every traffic class that BRS maintains. The minimum queue depth determines when BRS will discard incoming frames when the input device is low on receive buffers. Being low on input receive buffers means that the input device has x or fewer remaining buffers available in which to receive data, where x is equal to the low count as displayed by the talk 5 queue command.
BRS will return the buffer to the input device if the input device is low on input buffers and if the number of buffers in the queue to which the input frame would be added is currently equal to or greater than the minimum queue depth and less than the maximum queue depth. Regardless of whether or not the input device is low on buffers, the maximum queue depth determines the maximum number of buffers that will be queued in the priority queue. The minimum and maximum queue depth values should be increased along with the number of receive buffers per interface when input discards are detected. Input discards are displayed per interface by using the talk 5 statistics command.
Next, consider the traffic classes that are used to give bandwidth preference to the voice traffic. Traffic class definitions need be defined only if both voice and data will be multiplexed over the same PVC, because traffic classes do not interfere or interrupt each other across circuits. Voice should normally be given priority over any other traffic type for a PVC. To give priority to voice, you have the following two options:
BRS circuit classes may also be necessary to give bandwidth preference to PVCs carrying voice over those carrying only data. Circuit class definitions are only necessary when the sum of the CIRs for the circuits on the interface exceeds the access rate of the link. If the CIR total does not exceed the access rate, then the bandwidth percentages assigned to the circuit classes are not used because the FR traffic shaping function (that is, CIR monitoring) will override the circuit class bandwidth allocations. If the CIR total does exceed the access rate, then circuit classes should be defined with those PVCs carrying voice having higher bandwidth percentages than those carrying data only.
To access the FR configuration environment:
Config>network Network number [0]? 2 Frame Relay user configuration FR 2 Config>
This section outlines the minimum configuration steps that you are required to perform to get the FR protocol up and running. If you desire any further configuration information and explanation, refer to the configuration commands described in this chapter.
| Note: | You must restart the router for new configuration changes to take effect. |
There are three management options under Frame Relay:
FR defaults to ANSI enabled. If you want to change management types, or if you want to re-enable ANSI management, use the following procedure. Enabling management over FR is a two-step process:
See Table 43 for details of the management types available using the set command.
| Note: | The default value of the LMI network type is UNI (user-to-network interface). This is the most common configuration required when attaching the device to a public FR network. If an NUI (network-to-user) or NNI (network-to-network) interface is required, use the set LMI-network-type command to configure the interface appropriately. |
An example of how to set these management types is shown after the table. Also, refer to the enable and set command sections in this chapter for more information.
Table 43. Frame Relay Management Options
| Command | Options | Description |
|---|---|---|
| set | lmi-type rev1 | Conforms to LMI Revision 1 (Stratacom s Frame Relay Interface Specification) |
| set | lmi-type ansi | Conforms to ANSI T1.617 ISDN-DSS1-Signalling Specification for Frame Relay Bearer Service (known as Annex D) |
| set | lmi-type ccitt | Conforms to Annex A of ITU-T/CCITT Recommendation Q.933 - DSS1 Signalling Specification for Frame Mode Basic Call Control. |
FR SVC management is automatically enabled when SVCs are enabled.